Fixes #279 - #280

Fixes #279. Base: main b6f821a (the merge of #278). One commit: a50cc93.

Summary

A §4.6 re-confirmation names an ID: (id_kind, old_id, new_id, confirmed_on, both SHA-256). It does not name a folder. So Yes, remove of one folder recorded every channel ID that folder held, and that record accepted any change of those IDs. That included a saved header name lost in another folder that is still there, which the user never saw.

• description_removal.reconfirmations: a removal or rename answer now accepts a channel ID only when the channel has no other loss. A channel stays in open (publication refuses it as R_CONFIRMED_ID_CHANGED) when, besides what the answers touch, either of these holds:

  • it lost a position in a unit that no answer names. This is a move, and it still needs its own click on Channels (Notebook: no way to record a channel re-confirmation after re-ordering a unit's channels #258). The move's record is now the one written.
  • it lost a header name while a folder still there no longer gives a saved name at the channel's saved position (another name, or none).

  The folders and what was lost are returned in the new Reconfirmations.unseen.

• description_reconcile: each unit still in the folder carries headers_changed, the saved channels whose header name at their saved position is not a saved one. It uses the same comparison as _channels_differ, except that an empty name also counts when the channel has saved names.

• Notebook (Check and save): the line beside the disabled Save button names the channel and the folder, for example: "DNA lost a saved header name in ctrl/rep1, which is still there: a removal or rename does not confirm it (undo that tag on Channels)". The red R_CONFIRMED_ID_CHANGED at channels.DNA message above the button is unchanged. Nothing is confirmed for the user.

• A header name held only by the removed folder is still covered by the removal: every folder still there gives a saved name.

Spec interpretation

• The record cannot say "this ID, only in folder X". Experiment-v1 §4.6 keys reconfirmation by id_kind, old_id and new_id. The key set is fixed (RF4), and there is no folder or field key. So a channel with an unanswered change in a folder still there gets no record from the removal, and publication refuses it with R_CONFIRMED_ID_CHANGED (§4.6 (c)). I chose this safe side.
• Refuse rather than offer a click for a lost header name. Today there is no confirmation for a lost header name, even without a removal: Fixes #258, fixes #252 #278 does not offer one as a move, and the candidate is refused with "Undo that change". A removal elsewhere now leaves the same refusal in place instead of lifting it. Moves keep their own explicit click (Notebook: no way to record a channel re-confirmation after re-ordering a unit's channels #258), so for moves the "shown, own click" branch applies.
• An empty name now counts as a lost name (safe side). When a channel has saved names and a folder still there now gives no name at its position, the removal does not cover the lost name. Edge case: in a folder that never had names, a removal elsewhere that drops the only names now needs the tag change undone before saving.
• CLI describe: it does not share this logic. It holds no answers, so it never builds removal or rename re-confirmations (--publish refuses every draft built from the folders), and nothing changes there.

Evidence

• Regression test tests/test_reconfirm_scope.py::test_a_removal_does_not_accept_a_header_name_lost_in_a_folder_still_there[other-name|no-name]. Both cases fail on main (run against main's src) and pass here. The scenario:

  1. Save with ctrl/rep1 naming DNA "Hoechst".
  2. Rewrite that header to "Nuc" or to no name, and delete drug/rep2, which also holds DNA.
  3. Re-tag ctrl/rep1's channel 1 DNA, so "Hoechst" is no longer a DNA name.
  4. Click Yes, remove.

  Save is now disabled, save_experiment() refuses, the reason shows beside the button, and no record is written. On main it published with a DNA reconfirmation from the removal.

• Guards, which pass on main and here:

  • Without the re-tag, the removal still saves.
  • A header name held only by the removed folder is still covered by the removal, with one DNA record.

• Fixes #258, fixes #252 #278's tests all pass, including test_a_removal_elsewhere_does_not_confirm_a_move.

• Byte-identical publishes, main vs this branch: the SHA-256 of morphobricks.toml, experiment_design.csv and morphobricks.records.jsonl is identical in five scenarios:

  • first save;
  • header rename via header_names;
  • confirmed removal;
  • confirmed move;
  • move plus removal.

• Records files: the files written in those scenarios and by the new tests were checked with the Spec's tools/audit/refrecords.py check (MorphoBricks-Spec main b4b1008). All pass: "2 records OK" and "7 records OK" (×4).

• Spec: tests/spec_fixtures/ and tests/test_spec_*.py are untouched. 1732 passed, 0 skipped.

Tests

python tools/check.py on a50cc93 passed:

• ruff check: all checks passed;
• ruff format --check: 437 files already formatted;
• pytest: 5290 passed, 4 skipped;
• code rules: passed.

The 4 skips are environment-only:

• test_cli_log.py:166, test_folder_rules.py:199 and test_folder_rules.py:230: "this file system tells names apart by case";
• test_discovery.py:665: "running with permissions that ignore file modes".

The widgets were tested headless only. They were not looked at in JupyterLab or Colab.

Generated by Claude Code